作者简介：
曾庆国，来自阿里云智能-云原生可观测团队。过去多年一直从事云原生相关领域工作。从运营开源产品到商业产品研发；从应用交付、平台工程到深入云原生可观测。多次通过 KubeCon、ArchSummit、A2M、云原生峰会等平台分享云原生实践经验。今天给大家带来一个非常让人兴奋的话题，云原生全栈可观测。
业务系统具备良好的可观测性，是最容易让开发者、运营者和管理者兴奋的。为什么这样讲？当开发者做了非常棒的业务功能，把它发布上线，此时如果它是黑盒的，或许大家都感受不到更多的成就感。当研发同学能从一个观测大盘上看到业务功能有多少 PB 流量引入，业务系统稳定运行，资源消耗平稳且符合预期；业务运营同学可以看到目前有多少用户访问，用户的行为轨迹，产生了多少业务订单。这个时候才是让大家真正的安心和兴奋。回首过去几年，可观测伴随着整个云原生技术发展。Gartner 将 Applied Observability 列为 2023 年战略技术趋势，并预计，2026 年 70% 成功应用可观察性的组织将实现更短的决策延迟，为目标业务或 IT 流程带来竞争优势。多年之前，更多讲日志、监控、运维。近几年，随着云原生技术的发展，“可观测”一词变成大家必谈的点。围绕着现有云上需求，出现了一个更热的专业词 -- 全栈可观测。
我们认为目前及未来很长时间，全栈可观测将应用到各行各业及不同企业中去。所以，今天想跟大家聊聊，什么是全栈可观测及我们为什么需要它。
云上业务在可观测维度的挑战
首先，我们来看服务上云及上云以后，企业会遇到的可观测领域挑战。1）第一大挑战：数据孤岛
这个问题由来已久，且非常突出。举几个简单例子，企业用 ECS、容器、消息队列等不同产品都会提供可观测的数据，对于企业来讲，这些数据怎么关联起来，怎么有机形成关联整体并辅助后续决策？但通常这是割裂的。另外，在市场上、社区里有大量可观测相关项目、工具、产品，怎么去选择？当运维同学进行选择时候，面向运维的需求去选择某个工具集去更好做稳定性。当业务和产品同学进行选择时候，希望看到更多业务级数据辅助业务决策。不同需求出发，会选择不同观测集，这是很长时间出现的问题。今天我们讲全栈可观测的时候，核心就是解决这样的问题，在可观测领域里边如何解决数据孤岛问题。2）第二大挑战：成本
我们认为可观测是大数据的生意，意味着各方面成本非常高，最基本的就是数据存储、数据分析、全链路计算成本。其次，还包括怎么获取这些数据的技术、人力成本及业务上可能要更多消耗资源方面的成本。这些成本的膨胀会阻碍不同企业获得不一样的观测效果，大家看到可观测很理想、很美好，但当企业遇到成本问题时常常会退缩。3）第三大挑战：不同技术架构下如何保障稳定
第三个点也是我们做全栈可观测的初衷。大量行业业务特别是现在很多跨国企业及规模较大的企业，业务在云原生领域中快速扩展，变成多元化和分布式，不同的架构和技术栈层出不穷。对于这些业务如何确保他们的稳定性？如何拿到更好业务数据的观测？如何衡量更优的业务成本？这些都是需要我们去把这些数据从各种各样的维度，各种各样基础设施上或者不同业务服务上收集回来，形成最终可利用的数据集。换句话说，这些都需要两个字 -- 统一。云原生很关键的点叫做标准化统一，在云原生可观测领域里边，统一更加重要，需要我们更好地采集数据。4）第四大挑战：无法兑现的价值
不同的团队、不同业务方对可观测的需求是不一样的。如刚才所提到的，SRE 团队、稳定性团队更多的是要关注业务稳定性、业务运行状态等；研发同学关注资源消耗、架构状态等。业务或者运营的同学关注当前的业务数据，当前有多少 PV 进来了，多少 UV 进来了，然后形成了多少订单或者处理多少消息。这些需求形成了一系列的观测维度。针对不同团队、不同业务线需求时，观测怎么选择？怎么兑现观测数据的价值，显得更加的艰难。从这四个维度讲，我们看到了目前云原生可观测方面四大核心挑战，如何解决这些挑战？阿里云最近十年怎么做的？我们简单做一个回顾。
2013年-2023年，十年间我所在的团队就是阿里云云原生可观测团队，从最初的淘宝时代到现在的阿里云公有云商业服务。最开始的就是内部 EagleEye （鹰眼）产品，它的目的就是做分布式应用的追踪和分析，这种产品应对淘宝大量的流量和分布式业务架构非常关键。这个产品其实在对标到开源社区，也有类似当时提出来的概念——APM。随后的几年，从内部的工具孵化，变成了阿里云上公有云的服务，最开始还是围绕着 APM、Java 领域的应用监控这些维度来出发和深耕。随着云原生整个技术的发展以及可观测技术栈开源领域的发展，阿里云可观测产品逐步走向开放，围绕着开源领域已经形成的标准来制定整个的产品架构和体验。因此，我们逐步引入了全栈可观测能力，包括通常理解的前端到服务到 APP，以及后端运维以及基础设施、中间件产品等。从2022年开始，阿里云更多把整个全栈可观测的能力，端到端提供给的客户。全栈对于大多数客户来说去落地还是非常复杂，如何利用阿里云提供可观测的统一平台，快速达到比较理想的全栈可观测的状态，这是重点解决的问题。
围绕标准化，完全以 Prometheus，OpenTelemetry 的体系构建了后续的可观测数据，采、存、用全套机制。面向未来，更多的肯定就是把这种端到端全栈可观测的经验、平台能力和产品能力直接快速赋能给我们的每一个客户。不管是我们的业务团队做决策还是相关的平台团队做决策，亦或者站在更高的企业维度做决策，首先是了解可观测的优势。1）提供更好的业务运行的能见度，更好解决问题
企业上云和依赖大量 PaaS 产品成为主流，企业会用到大量的云产品。这个时候对于整个业务运行的能见度来说，不仅是自己写的代码，可能会涉及到当前使用到的所有云产品的成本情况、运行情况、资源消耗等，从而构建出整个业务运行的能见度。
所以，当我们能够统一进行观测、统一进行查看的时候，可以更快地定位问题。今天某一个业务出现问题，是什么原因导致的？是因为代码写的问题还是某个基础设施有问题？这就需要尽快进行定位。
特别是我们做一些 ToC 或者在线的业务，随时关注当前线上运行状态的观测数据，例如当前提供了一个推理服务，这个推理服务目前有多少用户进行调用，整个的响应是什么样的。如果发现我们用户的调用降低了，有没有可能是因为延迟太高，定位即可推动接下来加大运行资源的投入。这里只是举了一个小点，更多的其实是帮助我们从技术上，架构上，业务上做决策，必然会提供更多的数据支撑。3）省资源或者降成本的维度考量
我们知道业务运行状态包括了当前消耗资源的情况，整体的资源利用率的情况，当我们掌握它的变化趋势，会更明确做出判断，这个资源是不是分配太多了？可以降一降成本。降了成本以后，它的可靠性能否保障？这些都是可以从我们的趋势数据，整体观测的数据来衡量和决策。4）组织协作的维度上，由于可观测性的出现变得不一样
我们接触很多的团队，利用可观测的数据在不同的层级进行协作。让整个的业务运行，让业务整体数据更加透明以后，技术同学以及架构的同学各种维度观测的数据在同个数据池进行沟通的时候，就有沟通的桥梁。这是四个关键的优势。但任何事物不可能只有优势，没有劣势，哪有那么多银弹。1）复杂性
可观测系统是复杂系统，当你不知道怎么选择一个好的方案或者适合自己方案的时候，发现各方提供可观测数据，整体进行收集、处理、使用，选了很多的工具，这里边的技术门槛非常高，导致整个团队投入的成本也会变高。2）额外的资源消耗和性能开销
因为引入可观测性，业务应用旁边装了侵入式的探针。这个时候或多或少会给业务带来一些压力，以及整个系统性能的开销。当然，可观测技术在尽可能把这些侵入性或者把附加的资源消耗降低，但是避不了。采集大量数据的同时，必然消耗大量的资源。也会从另外一个维度带来成本的上升。3）组织文化成为变革阻力
如果说我们的组织文化没有形成数据驱动模式，落地全面可观测就会有阻碍和挑战，投入这么大的成本，带来的收益是什么？因为收益没有人用。4）数据安全和数据的可解释
这也是比较高的门槛。我们从基础设施到业务到上层自研的系统，都会产生不同的数据，每个数据代表什么含义，对于不同的人有不同的理解。如何让这些数据被不同有需求的人理解到找到，也是有很大的挑战。如何获得这些优势的同时，降低这些挑战，这是我们作为可观测厂商需要重点考虑的，也是为了帮助大家更好利用可观测的能力，是需要做的。今天就以这样的比较完整的方式呈现整个云原生可观测，给大家带来完整的方案思考。这里的标题有两个关健词，“场景化”和“数据”。什么是场景？场景其实就是应对不同的用户需求，所沉淀的不同的经验或者方案。比如现在应对我们 SRE 稳定性的需求，可能有具体的场景，给你对应的视图、告警配置等等。这套经验可以直接应用到业务体系里边去，确保稳定性观测落地。我们围绕着业务的需求的时候，要看到当前的用户量，用户访问的状态，以及转化的程度，对应用户观测维度相关的经验给到用户。最上层是场景的沉淀，场景的沉淀的话，目前对于公用的场景沉淀，还是分几个方面：第一方面，基础设施的层面，是大家公用的，不同的用户上来都会应用到的维度。第二方面，在业务应用领域，从前端到后端应用，形成全栈的应用可观测场景。第三方面，基于自身业务特征的自定义化。有了完整且标准化的数据集，用户通过相关的平台能力，能够自定义出自己一套观测的实践。简单来看一下，基础设施的维度，目前云原生领域基础设施核心就是容器以及传统的主机，云上各种各样的数据库服务，人工智能相关的服务，大数据服务。这些数据，云原生可观测平台已经支持这些维度的观测数据采集、富化和聚合。举个例子，某个业务团队复用企业云账号，在他们使用的各种云资源和云服务商，统一打上了团队标签。这个时候从可观测的数据视角可以基于这样的标签开始计算，当前这个业务团队的服务的消费是怎样的，资源消耗是怎样的，成本是怎样的，业务稳定性是怎样的，可以以不同的维度视角进行数据聚合，呈现出整个不同维度的观测力度。从应用的可观测的维度来看，通过各种各样的非侵入的和有侵入的、部分侵入的产品能力，比如 Java 应用的 APM，或者不同语言的基于 eBPF 应用的黄金三指标的分析。或者在前端的应用，APP 端都可以通过相关的数据采集的链路以及信息沉淀出这样的场景。支撑这样的场景当然需要有对应的平台的能力，这里的平台能力核心其实对于我们来讲几个重要的环节。一是数据接入能力，云上各种各样形态的数据呈现出来，大量的数据库实例，或者网关层面的实例，它是端到端的解决方案，不仅把数据采进来，这个数据会怎么样用，怎么画一个大盘，怎么构建告警规则。目前已经积累了大量的可观测生态能力。
围绕着“数据”方向，在平台能力侧提供可观测数据管理。观测数据逐步偏向于标准化，所以我们可以像数据库一样管理可观测数据。数据热点分布，维度分布，查询热点（慢查询）分布等等。细化的数据管理和加工有利于用户创造更多的观测场景，有的放矢的优化成本。平台能力的第三个维度就是告警平台和可视化、以及 AI 技术相关的数据聚合和数据解释能力。数据的背后有一个非常重要的模块，就是生成和采集数据的探针。ARMS 云原生可观测形成了从基础设施、云服务到后端应用、前端应用全栈的数据探针能力。在云上，用户可以透明化的利用这些探针采集全栈的数据。同时兼容 Prometheus，OpenTelemetry 等社区标准数据协议。根据 Metric、Trace 等不同的数据类型提供差异化的数据处理能力。最关键的是，云上数据采集的最佳实践已经原生落地。
数据在可观测领域里边具体有哪些形态？上面这个图非常的流行，目前可观测数据的四大数据类别：指标（Metrics）、日志（Logs）、应用链路追踪（Traces）和应用运行时分析（Profiles），它们适用于在不同的层面，可以一定层面的转化和交叉的关系。先来看指标的数据，最标准化的数据载体，体现的信息非常直接。当前有多少用户的访问，通过指标来表达的时候非常直接，有几个维度加几个标签，然后给一个确定的数值。Traces 处理复杂场景，长链路处理的时候，用到这种数据形态。它的核心点就是关联性很强，但是成本比较高，它更加趋向于日志，它的有效信息密度稍低。Profiles 数据，被开发者使用到，也就是软件的内部运行状态时候核心的利器，找到关键性的技术问题，内存的问题，CPU 消耗的问题。日志是使用面最广阔的可观测数据，也是成本非常高的，大量的日志不出问题的时候，或者不分析的时候是没有用的，更多的实践会把这种低密度数据往信息高密度进行转化。
有了数据选型以后，考虑数据的采集，我把它分为 4 类采集的面，考虑的技术要点不一样。1）容器
容器是云原生最重要的平台。对于 Kubernetes 这一套体系以及生态能力、平台服务，供给了大量的观测数据。包括：集群自身运行状态数据，集群工作负载数据以及运行应用自身的业务观测黄金三指标数据。对于Kubernetes 容器数据的采集，核心的点就是探针具备大规模的目标服务发现的能力。用户的单个集群可能存在大规模的采集目标，也可能有很高的变化频率，例如 AI 训练的任务 Pod，生命周期相对短，但是频繁进行更新。采集这些业务指标的时候就会面临高扰动的情况。基于大量的采集目标，不同的探针实例采不同数据的时候，涉及 Target 的调度和热迁移，这是为了数据的准确和稳定的关键点。在功能性方面，在容器集群采集的数据，一般会进行端侧处理，考虑哪些数据是重要的，或者哪些数据在端侧直接进行转化或聚合。具备数据处理 Pipeline 和默认规则是处理容器集群观测数据的关键。2）ECS 云服务器
云上面临大规模的 ESC 主机，我们的探针如何高效安装过去以及稳定的工作。和 K8s 不一样，ESC 没有标准的服务发现的能力，没有工作负载的控制能力。它的体系相对于容器显得不那么云原生。我们采集数据更多是无侵略的技术，分析主机自身物理资源状态，运行业务相关联的黄金三指标，同时识别他们的进程，进行数据关联以及打上相应的标签。比如机器上打了标签属于某个业务线，机器跑的进程服务相关联的数据同时打上对应的标签，以便于后续进行统计和聚合。3）Serverless 化的云服务
云服务 Serverless 对于用户来说更加简单和低成本，同时也更加黑盒。但对于可观测来说，我们需要采集内部 Serverless 环境采集下各种各样的云服务的指标，以及关联相关的观测数据。这里也会涉及到有特色的点，云服务的自动发现，某个用户创立了 Serverless 的数据库，观测平台将开始在内部采集这个实例对应相关联观测的数据，最后把数据呈现给用户，这是用户不可见的部分。4）业务应用
业务应用关联的采集，和业务要绑定在一块，这种技术形态目前有这么几类。一是 Java 类的 JVM 的探针；eBPF 无侵入的探针和针对某一类业务应用更加具体进行数据的采集和生成的 Exporter。伴随业务的探针需要更低的资源消耗，更高的稳定性。有了这些无处不在的探针能力以后，我们拿到了丰富的云上可观测数据。这些数据的存储怎么处理？过去的几年，不同的场景里面有不同的数据存储都是分离的，不统一。这种情况带来什么问题？用户选用这些工具的时候，没有办法把数据打通，同时它的使用、成本计算、规模计算都是分离的。在今年 ARMS 做了一个大升级，针对不同的可观测场景的数据的背后，都通过 Prometheus 的 Metrics 统一存储。这些场景，想观测的目标产生多少数据，统一按照数据量（GB）统一进行收费。在 ARMS 整体产品体系中你可以随意选择产品能力和场景能力，只需要为产生的数据量进行付费。这个的数据管理模式背后是大量的数据处理工作，针对应用监控、链路追踪、前端监控、云拨测等等业务领域，将核心数据处理统一转换为标准的指标格式。从数据形态上看即大量利用 Trace2Metric，Log2Metric 和自动化指标封装技术。
当然，统一数据的背后也会有一些原始数据的存储，比如跟踪的链路，在大多数情况下，热数据都是指标。因为它会把大量的链路追踪整个的计算结果变成指标存储起来。当然，也有少量的查询，背后会有冷数据，存储在原始的存储里边。这种存储相对成本更低，让整个存储的规范更加统一，以指标作为我们的核心存储。有了这样的采集存储以后，很关键的一个挑战就是成本。所以，从平台能力这一侧，千方百计要降低成本，举三个例子。
1）指标数据
大家使用面最广的观测数据形态，指标发散是高成本的拦路虎。例如现在要去统计我们的请求积累，如果在指标中直接存储请求的 Path 路径，这种数据大量的产生，而且没有多大的意义，成本累计上升。针对这些问题，有很多处理方式，有自动化的服务端直接处理的方式，采集侧最佳实践的处理方式，也有根据不同的数据类型，在端侧无损进行相关的聚合，核心的是降低成本。2）链路数据
链路追踪更多查询调用链里边的服务状态，热数据查询核心都是指标，整个链路数据的追踪查询相对低频。把整个调用链进行了冷热分离，整个热的数据都是先汇算成指标存起来以后，少量的查询才会到整个后面的冷数据，也是整个调用链。第二个维度是采样的考虑，错慢数据采样是目前实际应用最广的能力。3）日志数据
对于网关类服务的格式化的日志非常突出的形态，直接在端侧进行转化，不需要存储大量的日志，直接变成有效的指标进行存储起来，以供后续的计算和查询，平台具有一套开箱即用的产品能力。有了上面的一些核心的能力以后，另外非常重要的就是需要把这些平台的能力，以及数据采集、数据处理和可视化的经验有效归类起来，能够端到端提供给我们的用户。观测某一个已经存在的云服务、基础设施或业务应用，数据应该如何进行采集，哪些数据重要，如何进行数据关联可视化，如何配置告警最佳实践。这是有很高的门槛。对于大多数业务的公司或者团队来说，都是要考虑很久的问题。我们认为这些必然是经验的积累。我们面对大量的用户，总结各方实践经验并沉淀为可再次复用的能力集合。我们创造了一个 Observability As Code 的模式。在统一的平台能力之上，将数据采集、处理、数据存储、数据可视化和告警进行标准化的描述，形成可观测生态插件。目前云上可观测插件越来越丰富，已经覆盖了全栈领域，整体构建整个可观测的生态。
目前应用全栈可观测体系的客户基本上都比较类似，从需求、现状和痛点来看都是具有很多的共同性。如上文中提到的一些点。
对于传音控股的痛点是什么？云原生化整个上云改造，形成的观测对象非常多，因为使用大量的云服务、中间件、基础设施服务，还有业务分布在全球不同的区域。需要一个观测平台能够将整个业务体系覆盖到。第二，内部来说核心解决的问题就是业务的问题排查，问题的诊断作为第一需求，内部推广、应对团队的合作，如何利用可观测数据作为纽带，最后就是数据的集合，使用到不同服务的时候，他们产生的数据如何通过业务的需求聚合起来，这就是必然遇到的问题。从他们的方案来讲，利用 ARMS 可观测平台能力，构建全球的观测体系，数据整体都会构造到统一数据池子里，形成统一的数据追踪，最终形成了统一的视图。有几个关键的点：在无侵入方面，APM 的 Java 体系没有侵入的代码，相对无侵入。指标采集采用了大量内置的经验数据采集器，对于他们来说是完全透明的，其实都不需要感知采集器的存在，可以把他们的相关观测数据纳入到整个数据池。第二个维度，提供统一观测的能力。统一整个指标的体系观测告警，能够帮助用户更好地按照业务进行聚合，从而构建全球观测的体系。
全栈可观测的实践对于整个行业来看还处于比较早期的状态。当不同的企业在遇到某些契机的时候，才会开始引入这样的技术栈改造。从我们遇到的众多成功团队的经验看，内部的决策体系、内部的团队合作会带来显而易见的改变。
参考阅读：
本文由高可用架构转载。技术原创及架构实践文章，欢迎通过公众号菜单「联系我们」进行投稿